Method and apparatus for partitioning code in program code conversion

ABSTRACT

A partitioning technique utilized by a translator to divide the subject code space into regions, referred to hereafter as partitions, where each partition contains a distinct set of basic blocks of subject code and corresponding target code. The partitioning technique divides the translator&#39;s representation of subject code and subject code translations into non-overlapping regions of subject memory. In this manner, when the subject program modifies subject code, only those partitions actually affected by the self-modifying code need be discarded and all translations in unaffected partitions can be kept. This partitioning technique is advantageous in limiting the amount of target code that must be retranslated in response to self-modifying code operation. In another process, the partitioning technique allows multithreaded subject programs that also involve self-modifying code to perform code modification in a thread-safe manner

BACKGROUND

1. Technical Field

The subject invention relates generally to the field of computers andcomputer software and, more particularly, to program code conversionmethods and apparatus useful, for example, in code translators,emulators and accelerators.

2. Description of Related Art

In both embedded and non-embedded CPU's, one finds predominantInstruction Set Architectures (ISAs) for which large bodies of softwareexist that could be “accelerated” for performance, or “translated” to amyriad of capable processors that could present better cost/performancebenefits, provided that they could transparently access the relevantsoftware. One also finds dominant CPU architectures that are locked intime to their ISA, and cannot evolve in performance or market reach.Such architectures would benefit from “Synthetic CPU” co-architecture.

Program code conversion methods and apparatus facilitate suchacceleration, translation and co-architecture capabilities and areaddressed, for example, in the co-pending patent application entitledProgram Code Conversion, U.S. application Ser. No. 09/827,971.

During program code conversion of a subject program designed for asubject architecture to a target program executable by a targetarchitecture, a problem arises with respect to code that isself-modifying. “Self-modifying code” refers to a subject program thatintentionally modifies its own subject code. There are several reasonswhy a program might modify its own code, where some examples ofself-modifying code are listed in Table 1. TABLE 1 Examples ofSelf-Modifying Code Code Code Function Overlays Overlays are a mechanismused by systems that do not support virtual memory. To save addressspace, a single process can re-use a subject address range to hold dif-ferent libraries at different times. Such uses may or may not beassociated with system calls to mmap( ) and munmap( ). Trampolines Atrampoline is a short section of code constructed in the data area(i.e., on the stack or in the heap) that con- tains a call to codeelsewhere in the system. Code Patching Linkers and debuggers may modify(patch) existing code to implement linking or breakpoint operations.Run-Time This category includes dynamic binary translators and Compilersjust-in-time (JIT) compilers. Such programs potentially write manyfragments of subject code all over the data area. Signal Handler Asignal handler for SIGILL (illegal instruction) might modify the codethat caused the exception and continue.

One of the main problems presented by self-modifying code to dynamictranslators is that the subject code that was modified may correspond totarget code which has already been translated. When such a modificationof the subject code occurs, all translations of the modified subjectcode must be identified and discarded as stale. Thus, the translatormust be able to identify all target code sequences (i.e., translations)that correspond to particular subject code addresses being modified. Indynamic translators, finding and deleting the target code whichcorresponds to a given subject address is difficult and sometimes noteven possible. In some situations, optimizations are applied duringtranslation which yield translations that can no longer be exactlycorrelated to the range of subject addresses that the translationsrepresent. In these situations, if the subject program modifies its owncode at certain subject address, the translator has no way to identifywhich respective translated target code to invalidate.

SUMMARY

The following is a summary of various aspects and advantages realizableaccording to various embodiments according to the invention. It isprovided as an introduction to assist those skilled in the art to morerapidly assimilate the detailed design discussion that ensues and doesnot and is not intended in any way to limit the scope of the claims thatare appended hereto.

In particular, the inventors have developed a number of optimizationtechniques directed at expediting program code conversion, particularlyuseful in connection with a run-time translator which employstranslation of successive basic blocks of subject program code intotarget code wherein the target code corresponding to a first basic blockis executed prior to generation of target code for the next basic block.

In a preferred process, the translator employs a partitioning techniqueto divide the subject code space into regions, referred to hereafter aspartitions, where each partition contains a distinct set of basic blocksof subject code and corresponding target code. Partitioning divides thetranslator's representation of subject code and subject codetranslations into non-overlapping regions of subject memory. In thismanner, when self-modifying code in the subject program modifies subjectcode, only those partitions actually affected by the self-modifying codeneed be discarded and all translations in unaffected partitions can bekept. This partitioning technique is advantageous in limiting the amountof target code that must be retranslated in response to self-modifyingcode operations. In another process, the partitioning technique allowsmultithreaded subject programs that also involve self-modifying code toperform code modification in a thread-safe manner.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of the specification, illustrate presently preferredimplementations and are described as follows:

FIG. 1 is a block diagram of apparatus wherein embodiments of theinvention find application;

FIG. 2 is a schematic illustrating a basic block data structure andcache according to an illustrative embodiment of the invention;

FIG. 3 is a flow diagram illustrating a partitioning technique employedduring translation;

FIG. 4 is a flow diagram illustrating partition modification;

FIGS. 5A and 5B are schematic diagrams of an example illustrating thecreation and modification of partitions in the partitioning technique;

FIG. 6 is a flow diagram illustrating a reducible partition optimizationtechnique;

FIGS. 7A and 7B are schematic diagrams of an example illustrating thecreation and modification of partitions using a reducible partitionoptimization technique;

FIGS. 8A-8E are schematic diagrams of an example illustrating thecreation and modification of a partition having active and inactive SIGranges using a reducible partition optimization technique; and

FIGS. 9A and 9B are schematic diagrams of an example illustratingcontrol flow between partitions by the translator of the presentinvention.

DETAILED DESCRIPTION

Illustrative apparatus for implementing various novel features discussedbelow is shown in FIG. 1. FIG. 1 illustrates a target processor 13including target registers 15 together with memory 18 storing a numberof software components 19, 20, 21, where such memory 18 further providesa working storage for a basic block cache 23, a global register store27, and the subject code 17 to be translated. The software componentsinclude an operating system 20, the translator code 19, and translatedcode 21. The translator code 19 may function, for example, as anemulator translating subject code of one ISA into translated code ofanother ISA or as an accelerator for translating subject code intotranslated code, each of the same ISA.

The translator 19, i.e., the compiled version of the source codeimplementing the translator, and the translated code 21, i.e., thetranslation of the subject code 17 produced by the translator 19, run inconjunction with the operating system 20 such as, for example, UNIXrunning on the target processor 13, typically a microprocessor or othersuitable computer. It will be appreciated that the structure illustratedin FIG. 1 is exemplary only and that, for example, software, methods andprocesses according to the invention may be implemented in code residingwithin or beneath an operating system. The subject code, translatorcode, operating system, and memory storage mechanisms may be any of awide variety of types, as known to those skilled in the art.

In apparatus according to FIG. 1, program code conversion is preferablyperformed dynamically, at run-time, while the translated code 21 isrunning. The translator 19 runs inline with the translated code 21. Theexecution path of the translation process is a control loop comprisingthe steps of: executing translator code 19, which translates a block ofthe subject code 17 into translated code 21, and then executing thatblock of translated code 21; the end of each block of translated code 21contains instructions to return control back to the translator code 19.In other words, the steps of translating and then executing the subjectcode are interlaced, such that only portions of the subject program 17are translated at a time and the translated code 21 of a first basicblock is executed prior to the translation of subsequent basic blocks.The translator 19's fundamental unit of translation is the basic block,meaning that the translator 19 translates the subject code 17 one basicblock at a time. A basic block is formally defined as a section of codewith exactly one entry point and exactly one exit point, which limitsthe block code to a single control path. For this reason, basic blocksare the fundamental unit of control flow.

In the process of generating the translated code 21, intermediaterepresentation (“IR”) trees are generated by the translator 19 based onthe subject code 17 instruction sequence. IR trees are abstractrepresentations of the expressions calculated and operations performedby the subject program. Later, translated code 21 is generated based onthe IR trees. A method and apparatus for generating such IR trees aredescribed, for example, in the co-pending U.S. patent application Ser.No. 10/439,966, entitled Block Translation Optimizations for ProgramCode Conversion and filed on May 16, 2003, the disclosure of which ishereby incorporated by reference.

After the IR tree is generated, the corresponding target code 21 isgenerated based on the IR. The process of generating target code 21 froma generic IR is well understood in the art. Target code 21 is insertedat the end of the translated block to save the abstract registers to theglobal register store 27. After the target code 21 is generated, it isthen executed.

The translator 19 first generates translated code 21 based on thesubject instructions 17 of a first basic block, then the translated codefor the first basic block is executed. At the end of the first basicblock, the translated code 21 returns control to the translator 19,which then translates a second basic block. The translated code 21 forthe second basic block is then executed. At the end of the execution ofthe second basic block, the translated code returns control to thetranslator 19, which then translates the next basic block, and so forth.

Thus, a subject program running under the translator 19 has twodifferent types of code that execute in an interleaved manner: thetranslator code 19 and the translated code 21. The translator code 19 isgenerated by a compiler, prior to run-time, based on the high-levelsource code implementation of the translator 19. The translated code 21is generated by the translator code 19, throughout run-time, based onthe subject code 17 of the program being translated.

The representation of the subject processor state is likewise dividedbetween the translator 19 and translated code 21 components. Thetranslator 19 stores subject processor state in a variety of explicitprogramming language devices such as variables and/or objects; thecompiler used to compile the translator determines how the state andoperations are implemented in target code. The translated code 21, bycomparison, stores subject processor state implicitly in targetregisters and memory locations, which are manipulated directly by thetarget instructions of the translated code 21.

For example, the low-level representation of the global register store27 is simply a region of allocated memory. This is how the translatedcode 21 sees and interacts with the abstract registers, by saving andrestoring between the defined memory region and various targetregisters. In the source code of the translator 19, however, the globalregister store 27 is a data array or an object which can be accessed andmanipulated at a higher level. With respect to the translated code 21,there simply is no high-level representation.

In some cases, subject processor state which is static or staticallydeterminable in the translator 19 is encoded directly into thetranslated code 21 rather than being calculated dynamically. Forexample, the translator 19 may generate translated code 21 that isspecialized on the instruction type of the last flag-affectinginstruction, meaning that the translator would generate different targetcode for the same basic block if the instruction type of the lastflag-affecting instruction changed.

The translator 19 contains data structures corresponding to each basicblock translation, which are particularly useful in facilitatingtranslation optimizations, such as extended basic block, isoblock, groupblock, and cached translation state optimizations described in U.S.patent application Ser. No. 10/439,966 and incorporated by referenceabove. FIG. 2 illustrates such a basic block data structure 30, whichincludes a subject address 31, a target code pointer 33 (i.e., thetarget address of the translated code), translation hints 34, entry andexit conditions 35, a profiling metric 37, references to the datastructures of the predecessor and successor basic blocks 38, 39, and anentry register map 40. FIG. 2 further illustrates the basic block cache23, which is a collection of basic block data structures, e.g., 30, 41,42, 43, 44 . . . indexed by subject address. In one embodiment, the datastructure corresponding to a particular translated basic block may bestored in a C++ object. The translator 19 creates a new basic blockobject as the basic block is translated.

The subject address 31 of the basic block is the starting address ofthat basic block in the memory space of the subject program 17, meaningthe memory location where the basic block would be located if thesubject program 17 were running on the subject architecture. This isalso referred to as the subject starting address. While each basic blockcorresponds to a range of subject addresses (one for each subjectinstruction), the subject starting address is the subject address of thefirst instruction in the basic block.

The target address 33 of the basic block is the memory location(starting address) of the translated code 21 in the target program. Thetarget address 33 is also referred to as the target code pointer, or thetarget starting address. To execute a translated block, the translator19 treats the target address as a function pointer which is dereferencedto invoke (transfer control to) the translated code.

The basic block data structures 30, 41, 42, 43, . . . are stored in thebasic block cache 23, which is a repository of basic block objectsorganized by subject address. When the translated code 21 of a basicblock finishes executing, it returns control to the translator 19 andalso returns the value of the basic block's destination (successor)subject address 31 to the translator. To determine if the successorbasic block has already been translated, the translator 19 compares thedestination subject address 31 against the subject addresses 31 of basicblocks in the basic block cache 23 (i.e., those that have already beentranslated). Basic blocks which have not been yet translated aretranslated and then executed. Basic blocks which have already beentranslated (and which have compatible entry conditions, as discussedbelow) are simply executed. Over time, many of the basic blocksencountered will already have been translated, which causes theincremental translation cost to decrease. As such, the translator 19gets faster over time, as fewer and fewer blocks require translation.

Partitions

In a preferred embodiment, the translator 19 employs a technique toselect sets of subject instructions, referred to hereafter as subjectinstruction groups (SIGs), in order that each SIG is associated with adistinct set of translator data structures (e.g., basic blocks) andtranslated target code 21. The combination of a SIG and it's associatedtranslator data structures and target code 21 is hereafter referred toas a partition. A single SIG includes subject instructions in one ormore ranges of subject addresses. Instructions from a single subjectaddress or ranges of subject addresses may be included in severaldistinct SIGs. A translated block may only include translations from oneSIG.

The partitioning technique utilized by the translator 19 divides thetranslator 19's representation of control flow into groups of subjectinstructions (SIGs) which are likely to be modified together. In somecases, these partitions correspond to the different libraries and objectfiles that make up a subject program, such that partitions are createdand replaced as libraries are mapped into subject memory and laterdiscarded. The partitioning technique can be particularly useful to thetranslator 19 when translating subject programs that modify their ownsubject code 17, hereinafter referred to as “self-modifying.” Bydividing subject code 17 and its corresponding translated target code 21into partitions, the affected partition or partitions can be discardedwhen their associated subject code is modified without affecting thevaluable information (e.g., translations) built up in other partitionswhose SIGs are not affected. Without the use of such partitions, allexisting translations, even those not affected by the code modification,would need to be discarded in response to every code modification.

In a preferred embodiment, the translator 19 maintains segregated datastructures, such that translation data structures are organized by SIGsinto partitions. This segregation allows for the numerous blocktranslations (and affiliated data structures) that are contained withina single partition to be discarded and freed at once, rather thantraversing the underlying representations of translated code to searchfor affected translations and deleting them one at a time. For example,in one embodiment the translator 19 maintains a separate basic blockcache 23 for each partition.

In a preferred embodiment, the translator 19 defines SIGs such that thesubject addresses in a single SIG form a single contiguous range ofaddresses.

In another preferred embodiment, the translator 19 defines SIGs suchthat the subject addresses in a single SIG are composed of (1) a singlerange of contiguous addresses that are likely to be modified together,plus (2) additional ranges of addresses that are less likely to bemodified. This allows the translation of a single block to includeinstructions from the range (1) and the ranges (2) and thereby form amore optimal translation.

The steps implemented by the translator 19 in modifying partitions areillustrated in FIG. 3. When subject code 17 modifies other subject code,the “modification event” is detected in step 100 by the translator 19. Amodification event is defined to correspond to a particular subjectaddress range (the range of subject code that is overwritten, deleted orotherwise affected by the modification). The translator 19 must firstdetect when and where subject code is self-modified (i.e., which subjectcode performs the modification, and which subject code is modified).Modification events are any events which cause subject code 17 to bemodified. Self-modifying code does not include cases in which subjectcode 17 modifies subject data. Self-modification of subject code 17 cantake many forms, including but not limited to: (i) mapping a file intomemory (e.g., mmap( ) system calls); (ii) removing a file from memory(e.g., munmap( ) system calls); and (iii) making a memory regionexecutable (e.g., changing its permissions using the mprotect( ) systemcall).

In cases where subject code 17 modifications are made using a well knownsystem call, such as mmap( ), munmap( ) or mprotect( ), the translator19 may detect all calls to that system call in the subject code 17 inorder to detect the modification event. The translator 19 can alsodetect subject code 17 modifications by other mechanisms. For example,many subject processors require that, prior to executing code that hasbeen modified, the subject program must first flush the processor'sinstruction cache (I-cache). In particular, the PowerPC architecture hasa special instruction for this purpose, “ICBI” (Instruction Cache BlockInvalidate), while other architectures may use a special system call forthe same purpose. On architectures with such a cache flush requirement,the translator 19 may detect modification events by detecting instancesof the special instruction (or special system call).

In another preferred embodiment, the translator 19 uses features of thetarget operating system 20 to monitor all writes to target memoryregions corresponding to subject code in order to detect modificationevents in step 100. On certain systems, the system call mprotect( )allows the translator 19 to set particular regions of memory as being“read-only.” Other systems may utilize equivalent functions to that ofthe mprotect( ) system call to define a particular area of memory asbeing read-only. Any attempt to write into read-only regions triggers asignal which is detected by the translator 19. The signal notifies thetranslator 19 that a subject code 17 modification is taking place, andthe translator 19 uses the signal context to determine which subjectaddresses are being overwritten. After detecting the modification eventand identifying the scope of the modification (i.e., the subjectaddresses affected), the translator 19 then allows the write to proceednormally.

In another preferred embodiment, the translator 19 generates a specialtarget code sequence, for each translated memory write operation in thesubject code 17, which checks if the write address corresponds tosubject code 17 rather than subject data, in order to detectmodification events in step 100.

In each of the various embodiments of the present invention, after amodification event has been detected, the modification results in thecreation of a new partition in step 102 whose SIG includes the subjectinstructions in the modified range. In addition, existing partitions arethen modified in step 104 to account for the newly created partition. Inmodifying the existing partitions, the translator 19 implements thesteps illustrated in FIG. 4. When the translator 19 creates a newpartition as the result of a detected modification event, it isinitially determined in step 110 whether the SIG of the newly createdpartition intersects with the SIG in any existing partitions. When nooverlap with the SIG of an existing partition is found, the existingpartitions are left intact in step 116. If any existing partitions hadSIGs that included subject address ranges that intersected (overlapped)with the modified range, all such intersecting partitions are destroyedin step 112 and recreated in step 114, except in certain situationswhere additional partition optimizations are applied as described below.For each intersecting partition that is destroyed, a new remainderpartition is created in step 114 for the remaining range or ranges ofsubject addresses in the original SIG, such that the new remainderpartition contains the original SIG of the intersecting partition minusthe intersecting modified range. When a partition is destroyed, allexisting target code 21 translations associated with that partition arediscarded. Each newly created partition is, at first, completely emptyof translated target code 21, meaning that any subject code 17subsequently encountered from the SIG of that partition must betranslated from scratch.

FIGS. 5A and 5B illustrate an example of the creation of a new partitionfrom a set of existing partitions and a modification event whichoverlaps some of those partitions. For the purposes of providing asimple illustrative example, FIGS. 5A and 5B depict SIGs in which theset of subject instructions for each SIG forms a single contiguousrange, but it is not essential to the technique for each SIG to containa single continuous range. Prior to the modification, the SIGs of fourpartitions A, B, C and D exist in the subject address space as shown inFIG. 5A. The subject code 17 in this example then modifies a range ofsubject code addresses extending from point 50 in memory to point 52.The range of the modification 54 intersects with the SIGs for partitionsA and C and totally encompasses the SIG for partition B. FIG. 5Billustrates the changes made to the existing partitions in response tothe modification event. Partition M is created for the entire modifiedrange 104. Partitions A and C are destroyed, and partitions A′ and C′are created, respectively, for the remaining portions of A and C whichdo not intersect the modification range 104. Partition B is destroyedand its SIG is completely subsumed by the new partition M. Partition D,whose range does not overlap the modification range 54, remainsunaffected.

In another preferred embodiment of the translator 19, a lazy partitionallocation optimization technique is utilized by the partitioningtechnique in order to improve performance of the translator 19. In orderto save memory, the full data structures of a partition are notallocated at the time when a partition is created. Instead, an inactivepartition is initially created which reserves the partition's SIG, butthe translator 19 does not initially allocate any of the underlyingtranslation data structures and memory. In this manner, the initialinactive partitions are essentially empty skeleton partitions thatmerely reserve a particular SIG. The regions of the subject memory spacewhich the translator 19 identifies as being modified by a modificationevent may in certain situations never actually be translated into targetcode 21. This may be because the subject memory region corresponds todata, or because the subject memory region corresponds to code which isnever executed. The initial creation of the inactive or skeletonpartition avoids the overhead of wasted memory resources.

When any subject code 17 within the SIG of a partition is actuallytranslated, the inactive partition becomes a live or active partitionand the partition data structures are initialized. Accordingly,modification events which correspond to data segments of the subjectprogram (e.g., files which are mmap( )ed as data, and which the subjectprogram never executes as code) cause a new inactive partition to becreated, but none of the underlying translation data structures andmemory regions are allocated. The partition's full data structures areonly realized when translation occurs within the partition's range ofsubject addresses. Because inactive partitions contain no translationsof subject code, they can be created, deleted, or resized without thememory and performance overhead associated with live partitions

In certain situations, the translator 19 may allocate large regions ofmemory for new partitions to store target code 21 translations. Targetcode 21 is preferably allocated to be contiguous so as to avoidunnecessary fragmentation. The translator 19 is more likely to be ableto make target code 21 contiguous if it has a large memory region touse. Partitions which are falsely detected (i.e., modification events insubject memory ranges which do not correspond to executable subjectcode) can sometimes consume valuable memory resources for no purpose. Byonly allocating translation data structures and memory when subject code17 within a partition is actually translated (and executed), lazypartition allocation allows the translator 19 to avoid the negativeimpact of false positives from the modification event detectionmechanism associated with partitioning.

In another preferred embodiment, the translator 19 possesses interpreterfunctionality to interpret subject code 17 rather than translate it.This allows the translator 19 to delay the translation of subject code17 and thereby avoid the allocation of partitions associated with thatsubject code 17. A translation method and apparatus which facilitatessuch interpreter functionality is described in co-pending UK PatentApplication Serial No. 03 20716.4, entitled “Method and Apparatus forPerforming Interpreter Optimizations during Program Code Conversion,”filed on Sep. 4, 2003, the disclosure of which is hereby incorporated byreference.

In another preferred embodiment, the translator 19 applies a reduciblepartition optimization technique to the partitioning process in order toimprove performance of the translator 19, where the SIG of a partitionis reduced, rather than deleting the partition in response to amodification event, to a smaller SIG that includes the set of addressesactually used in the partition. The reduced smaller SIG does not includethe range defined by the modification event. Initially in response tothe detection of a modification event, a new partition is created with aSIG including a range with a starting address and an ending addresswhose values are defined by the scope of the modification. However, inoperation, the actual range of subject addresses that are translated maybe narrower than the defined range of the partition. The SIGencompassing all subject addresses within a partition that have actuallybeen translated or which are flagged for future translation is referredto as the “active SIG” or used SIG of a partition. The remaining SIG ofsubject addresses in a partition that have not been translated isreferred to as the “inactive SIG.” In order to optimize the performanceof the translator 19, the extent of the SIG of a partition may bereduced, from its initially defined set of addresses to a lesser setwhich includes its active range of addresses in the active SIG byeliminating at least a portion of the inactive range of addressescorresponding to the intersection between the inactive SIG and the rangeof the modification.

While the concept of reducible partitions may be implemented in anynumber of ways, in one preferred embodiment, the translator 19 maintainsthe active range or translated range of addresses in the SIG of eachpartition. When a partition is created, its active SIG is initiallyempty. During translation, as each subject instruction is translated,its subject address (“the translated address”) is compared to the activeSIG of the current partition. If the translated address is outside thecurrent active SIG, the active SIG is expanded to include the translatedaddress. As such, the active SIG will grow as translation of the subjectcode progresses.

In performing the reducible partition optimization technique, thetranslator 19 implements the steps illustrated in FIG. 6. When thetranslator 19 detects a modification event in step 200, a new partitionis created in step 202 with a SIG including the range of themodification. The translator 19 then determines in step 204 if the rangeof the modification overlaps the initially defined SIG of an existingpartition. When no overlap is found, already defined existing partitionsare left intact in step 206. If an overlap exists, the translator 19then determines in step 208 whether the modification range actuallyoverlaps the partition's active SIG. If the modification range does notoverlap the active SIG, then the translator 19 can simply resize thepartition's initially defined SIG in step 210 without deleting thetranslation data structures within the partition. The reason is that,while the initially defined partition SIG represents the potential scopeof the partition, as defined by the prior modification event whichcreated the partition, the active SIG represents the actual set ofsubject addresses translated. Modifications which do not overlap theactive SIG therefore do not invalidate any of the translations withinthe partition, because the translator 19 knows that the translatedsubject addresses are distinct from, and therefore unaffected by, themodified subject addresses. By resizing the SIG of a partition toinclude at least the active range, the translations stored within thepartition can be kept in that partition and need not be deleted. On theother hand, if the modification range does overlap the partition'sactive SIG, then the translator 19 must delete the entire partition instep 212 as described above.

Referring now to FIGS. 7A and 7B, an illustration of the reduciblepartition optimization technique is provided. The partitions illustratedin FIGS. 7A and 7B are substantially the same as those shown in FIGS. 5Aand 5B, except that partitions A and C include active ranges of subjectaddresses 56 and 58, respectively. Prior to the modification, fourpartitions A, B, C and D exist, as shown in FIG. 10A. The subject codethen modifies a range of subject code addresses extending from point 50in memory to point 52. The range of the modification 54 intersects withthe initially defined partition range for partition A, but the range ofmodification does not intersect with the active range 56 of partition A.FIG. 7B illustrates the changes made to the existing partitions inresponse to the modification event. After partition M is created for themodified range 54, the range of partition A can be reduced withoutaffecting the translations in partition A. Contrarily, it can be seen inthis example that the range of modification 54 intersects with theactive range 58 of partition C. Thus, the range of partition C can notsimply be reduced and partition C must be destroyed, whereupon newpartition C′ is created for the remaining portion of partition C whichis not intersecting with the range of modification 54. Partition B isdestroyed and its range is completely subsumed by the new partition M.Partition D remains unaffected.

Referring to FIGS. 8A-8E, an illustration of the reducible partitionoptimization technique is provided in which a SIG 300 exists whichcontains multiple active and inactive ranges. FIG. 8A illustrates theinitially defined SIG 300 as it appears in the subject address space302. The SIG 300 includes two ranges of subject code addresses 304 and306. As shown in FIG. 8B, each of the subject code address ranges 304,306 includes an active range of subject code addresses 308, 310,respectively. The remaining subject addresses in the SIG 300 areinactive subject code addresses located in inactive ranges 312, 314, and316. Upon the occurrence of a modification event, the subject code thenmodifies a range of subject code addresses to create a new SIG 318 asillustrated in FIG. 4C. The range of the newly created SIG 318intersects with the initially defined subject code address range 304 ofSIG 300, where the range of SIG 318 does not intersect with its activerange 308 but only its inactive range 314. After determining the scopeof the range of SIG 318, the subject address range 314 can be reduced asshown in FIG. 4D without affecting the translations in the active range308 of SIG 300. The inactive range 314 is reduced by removing thesubject addresses in the range of intersection 320 with the SIG 318 toproduce a reduced inactive range 314′. FIG. 4E illustrates the changesmade to the initially defined subject address ranges 304, 306 of SIG 300in response to the modification event. As can be seen, initially definedsubject address range 304 is reduced as described above to subjectaddress range 304′ which includes active range 308 and inactive ranges312, 314′. Subject address range 306 remains unaffected by the creationof new SIG 318.

The translator 19 can detect most modification events at decode-time,but the actual subject addresses to be modified may not be known untilthe translated code 21 is executed. Thus, when the translator 19 detectsduring decoding either a subject code 17 modification or an indicationthat a modification has occurred, the translator 19 ends the translationof the current block, and inserts a notification immediately after thecurrent block to notify the translator of the modification event.

In one embodiment of the translator 19, the partitioning technique isimplemented in the translator 19 with the aid of special blocks. Specialblocks are blocks which, while they may correspond to a particularsubject address do not represent translations of subject code. Incontrast, a translation block represents a translation of a particularsubject code sequence beginning with a particular starting subjectaddress. Instead, special blocks contain special actions of thetranslator 19 which are inserted into the stream of target code duringtranslation, before the blocks are actually executed. In effect, specialblocks are special translation structures that perform lightweighttranslator actions, which can be planted at particular points in thetarget code control flow without requiring an expensive context switchout of target code back to the translator loop.

Special blocks contain pseudo-target code rather than normal targetcode. Normal target code represents a translation of some subject codesequence. Pseudo-target code consists of artificial (i.e., nottranslated) target code sequences, which is either written directly intarget code or written in a high-level programming language (e.g., C++)and compiled to have the same calling conventions as target codegenerated by the translator 19. Examples of special blocks includenotifyBlocks and border guard blocks, which are discussed herein.

In a preferred embodiment, the translator 19 inserts a special blockcalled a “notifyBlock” into the control flow of the translated programat a point immediately following the block containing the self-modifyingsubject code. The notifyBlock is a “special” translation structure,because unlike a translation block it does not represent the translationof any particular subject code, but rather it represents themodification event. The subject code 17 which actually performs themodification is translated as part of the current block. The notifyBlockis inserted as the successor of the current block. Thus, immediatelyafter the modification is performed in the translated current block, thesubsequent notifyBlock notifies the translator 19 to perform theappropriate actions in response to that modification (i.e., partitionadjustments). The subject code 17 that follows the modification event istranslated in a new block, which becomes the successor of thenotifyBlock.

When the notifyBlock is reached in the target code 21 at run-time, thetranslator 19 is notified of the subject address range of the modifiedcode. The translator 19 uses this information to create a new partition,which may also alter or destroy existing partitions as described above.

The block containing the self-modifying subject code (the predecessor ofthe notifyBlock) ends immediately after identifying a modification eventbecause the modification may invalidate the current partition. Themodified subject code might be the next subject instruction, which wouldrequire the translator to translate and execute the newly modifiedversion of that instruction rather than executing an existingtranslation of the old version. For example, on the PowerPCarchitecture, a block must end after a cache flush instruction. Thus,when a modification event is detected, the current block of translationis ended and a notifyBlock is inserted as the successor.

The notifyBlock also passes a copy of the current subject address andcompatibility list from its predecessor block to its successor block.After the notification occurs, translation resumes in the successorblock at the next subject instruction. If the current partition isdestroyed as a result of the operation, the notifyBlock also handles thesafe transition into the new partition which replaces it, using thecopied subject address and compatibility list to initialize thesuccessor block in the new partition. This avoids the problem ofreferring to data which may have become deleted during the transition tothe new partition.

Translation blocks must end at partition boundaries, such that thecreation of partitions can have a negative impact on optimizations whichcould otherwise be performed on large sections of code. Sections of codewhich would otherwise be translated together are translated as separateblocks due to the partitions formed, thus reducing the scope of theoptimizations and increasing the number of returns to the translatorloop. For example, optimizations, such as the extended block and groupblock optimizations described in co-pending U.S. patent application Ser.No. 10/439,966 and assigned to the same assignee as the presentinvention and hereby incorporated by reference herein, are limited bypartition boundaries. For this reason, one optimization that can beapplied to the present partitioning technique in order to improveperformance of the translator 19 is, for subject programs that are knownnot to modify their own subject code 17, aggregating all subject memoryinto a single partition such that all subject code 17 is contained inone partition.

Subject memory aggregation can be implemented in a number of manners. Inone approach, a set of libraries that are known not to be modified innormal operation are aggregated into a single partition. Remaininglibraries that are required by the subject program that are not part ofthis immutable set are placed into separate partitions as normal. Thisallows the translations in the immutable partition to be translated moreefficiently, while maintaining the ability to respond to subject codemodification of the remaining, possibly mutable, libraries and othersubject code.

In another approach to subject memory aggregation, a region (1) ofsubject addresses enclosing a set of subject code which is known not tobe modified in normal operation is added to the SIGs of all partitionswhich separately contain other regions (2) which may be mutable, whichallows the translation of control flow which passes from the possiblymutable region of the partition into the immutable region to begenerated more optimally, while maintaining the ability to respond tosubject code modification of the mutable regions of the partition. If asubject code modification occurs that encompasses the whole of region(2) of the partition, the partition will be deleted in it's entirely inorder to save memory.

The scope of a partition must be properly defined, because the partitionscope impacts the performance of the translator 19. If partitions aretoo small, control flow must constantly pass through border guards(described below). If partitions are too large, a slight codemodification will unnecessarily invalidate larger portions of translatedcode. A proper balance of such constraints should be considered whenselecting partition size as it relates to the performance of thetranslator 19. Optimizations can be applied to the partitions if it isdetermined that the particular partitions being generated have anegative impact on performance. By default, partition size is determinedby the modification event detection mechanism. For example, if thetranslator 19 detects an mmap( ) of a run-time library, a new partitionis created that encompasses the entire library.

One optimization technique that can be applied to partitioning in orderto improve performance of the translator 19 is the aggregation ofpartitions. For example, the PowerPC ICBI cache flush instructioninvalidates one page of executable memory. However, if multiple pages ofsubject code 17 are modified at once, the subject program may containseveral consecutive ICBI instructions which invalidate contiguous pagesof memory. Under the partitioning mechanism described above, this wouldresult in multiple, contiguous, page-wide partitions. As such, oneoptimization of the partition mechanism is to detect consecutive cacheflush instructions and coalesce the modified ranges into the SIG of one“aggregated” partition.

In one embodiment implementing the partition aggregation optimization,when a new partition is created, the translator 19 checks if there is anexisting partition (i.e., not a remainder partition created as abyproduct of the new partition's creation) that has a SIG that isadjacent to and precedes the new partition's SIG in the subject code. Ifso, the range of the preceding existing partition's SIG can be expandedto include the range of the new partition's SIG, effectively aggregatingthe two partitions. The new partition need not have a separaterepresentation after the aggregation has occurred.

Border Guards

In a preferred embodiment, the translator 19 inserts an additional levelof indirection for control flow that travels between partitions. Thetranslator 19 uses special placeholders, referred to herein as borderguards, for blocks that touch partition boundaries, so that predecessorblocks can check if previously translated successor blocks still exist.With this approach, predecessor blocks can be efficiently notified whentheir successors are deleted. The translator 19 inserts a pair of borderguard structures at every point where the subject program's control flowcrosses a partition boundary, otherwise referred to as border crossings.The pair of border guards includes an exit border guard and an entryborder guard. An exit border guard is a special block which is addedafter, and in the same partition as, the predecessor block. An entryborder guard is a data structure which connects the corresponding exitborder guard block to the successor block. For translated blocks withinthe same partition, control flow passes directly from the predecessorblock to the successor block. For blocks in different partitions (i.e.,border crossings), control flows from the predecessor block to an exitborder guard, then using the entry border guard to locate the successorblock, the exit border guard passes control to the successor block.

Entry border guards serve as placeholders for the translator 19, whereentry border guards store references to their exit border guardcounterparts. The data structure of each exit border guard also containsa reference to its entry border guard counterpart. The execution of anexit border guard verifies that a previously instantiated successorblock still exists. Border guard blocks serve a bookkeeping function byproviding an explicit representation of partition crossings. When thetranslator 19 deletes a particular partition, it traverses every entryborder guard within that partition to find the corresponding exitguards. As the partition is deleted, the counterpart reference of eachsuch exit border guard is set to null. In some embodiments, thetranslator 19 stores all of the entry border guards for a givenpartition together, such that they can be traversed efficiently when thepartition is deleted. For example, in one embodiment, the translator 19maintains an entry border guard list for each partition, wherein suchlist is updated whenever entry border guards are created or deleted.

Accordingly, when an exit border guard is executed, it verifies that itssuccessor still exists by simply checking its own counterpart reference.If the reference is defined, then a valid translated successor existsand control passes via the respective entry border guard into thesuccessor block, (and thereby to the successor partition). If thereference is undefined, then the exit border guard is unaware of a validtranslated successor block, meaning that either there was one and it wasdeleted or this exit border guard has never been executed and thereforethe successor has never been determined. If the counterpart reference isundefined, a new entry border guard and successor block are obtained byeither checking the basic block cache of the respective partition ortranslating the successor block. From the exit border guard'sperspective, a successor block that was translated and subsequentlydeleted is indistinguishable from a successor block that has never beentranslated.

The explicit representation of partition border crossings achieved bythe border guard pair makes the process of partition deletion moreefficient. To delete a partition, the translator 19 must identify andnullify all references to deleted blocks (i.e., previously translatedblocks within the deleted partition). Absent some bookkeeping mechanism,such as border guards, the translator 19 would need to traverse numeroustranslated blocks to identify which blocks had successors in the deletedpartition, in order to remove the references to those discardedsuccessors. In addition to making the process of deleting a partitionmore efficient, border guard blocks facilitate thread-safe bordercrossings, as discussed below with respect to multithreaded programs.

To delete a partition in the presence of border guards, the translator19: (i) voids the counterpart links of all exit guards that point to thepartition to be deleted, and (ii) notifies all successor partitions ofthe partition to be deleted that their corresponding entry guards can bediscarded, and (iii) deletes all translation structures and target code21 belonging to the deleted partition. In the first step (i), thetranslator 19 traverses all of the entry border guards in the partition,and resets their foreign exit border guard counterparts, effectivelynotifying all predecessor partitions that the deleted partition is void.In the second step (ii) of partition deletion, all of the exit borderguards in the partition are traversed to notify the successor partitionsthat their corresponding entry guards can be discarded. In oneembodiment, the second step is performed by traversing each exit borderguard of the deleted partition. In another embodiment, all of the entryguards in a partition are indexed by the predecessor partition whichcontains the corresponding exit guard. In this case, the deletedpartition need only notify each successor partition once, and eachsuccessor partition can then identify the corresponding entry points tobe deleted.

Multithreaded Programs in Partitioning

Multithreaded subject programs present a difficulty to the translator 19when utilizing partitioning, namely the deletion of partitions must beperformed in a thread-safe manner. Specifically, while a given partitionis being deleted, threads must be prevented from entering thatpartition. This guarantees that control always flows into validtranslations, and never into a deleted or invalid block. After apartition has been deleted and recreated, threads may then be allowed toenter the (newly emptied) partition.

In a preferred embodiment, the translator 19 uses a single global mutex(“the global partition lock”) to serialize particular partitionoperations, including: (i) control flow jumps between partitions (i.e.,border crossings); and (ii) deletion, and where applicable re-creation,of partitions. Thus, an exit border guard must acquire the globalpartition lock before control passes to its corresponding entry borderguard. Likewise, a notifyBlock must acquire the global partition lockbefore destroying a partition. For modification events that require thedeletion and subsequent re-creation of one or more partitions, all suchdeletions and re-creations are performed atomically under the protectionof the global partition lock, meaning that all such operations areperformed in sequence without releasing the lock. The translator 19maintains a partition identifier for each thread, which is changed whencontrol passes between partitions. This change is made by a border guardpair while holding the global partition lock.

In another preferred embodiment, the translator 19 uses a single globalmutex (“the global partition lock”) to serialize particular partitionoperations: (i) creation of entry border guards; and (ii) deletion, andwhere applicable, re-creation, of partitions. Thus, an exit border guardmust acquire the global partition lock before it can obtain a new entryborder guard and successor block, or re-create a previously deletedentry border guard and successor block. In the event of partitiondeletion, the notifyBlock obtains the global partition lock beforedeletion, and then the deletion mechanism first performs operation oftraversing its collection of entry border guards in order to remove thecounterpart references from the corresponding exit blocks. This requiresthat an individual counterpart reference can be safely unlinked in thepresence of other threads of execution. Once all of the entry borderguards have had this operation applied, the rest of the deletionoperation must complete and the global mutex be released before any ofthe exit border guards so modified can obtain a new successor in the SIGowned by the deleted partition.

Referring now to FIGS. 9A and 9B, the control flow of a translatedprogram across partition boundaries is illustrated, both with andwithout crossing a partition boundary. FIG. 9A shows the control flow ofa particular subject program in the translator 19 when partitioning isnot being employed or when control flow remains within a singlepartition. Control passes from subject block A 401 to subject block B403, then to subject block C 405, then to subject block D 407. In termsof the program subject code, block B 403 is block A's 401 successor,block C 405 is block B's 403 successor, and block D 407 is block C's 405successor.

In the situation where a partition boundary 409 existed or was createdbetween subject block B and subject block C of FIG. 9A, control wouldnecessarily flow through a border guard pair when crossing the partitionboundary 409, as illustrated in FIG. 9B. Blocks A 401 and B 403 are bothin partition 415, while blocks C 405 and D 407 are both in partition417. In the translated subject program, control passes directly fromblock A 401 to block B 403, because blocks A 401 and B 403 are in thesame partition 415. The transfer of control from block B 403 to block C405, however, crosses a partition boundary. As such, control passes fromblock B 403 to an exit border guard block 411. As described above, theexit border guard 411 checks that its corresponding entry border guard413 has not been deleted. In a multithreaded program (discussed below),the exit border guard also acquires the global partition lock, so thatthe partition boundary can be crossed in a thread-safe manner. Controlthen passes from the exit border guard block 411 to its correspondingentry border guard 213. Execution has now passed into partition 417. Ina multithreaded program (discussed below), the entry border guardchanges the partition identifier of the current thread to reflect thefact that the thread is now in partition 417 and the global partitionlock is then released. Once inside partition 417, control passes fromthe entry border guard 413 to block C 405, and then directly from blockC 405 to block D 407.

Memory Management

Memory management is a critical consideration in the various embodimentsof the dynamic binary translator 19. The memory demands of translating aprogram for execution on one architecture to allow execution on anotherarchitecture are high. The memory demands become even higher whenoptimizations, such as isoblocks, extended blocks, and group blocks, asdescribed in co-pending U.S. patent application Ser. No. 10/439,966, areintroduced, as each of these optimizations creates the possibility thatone sequence of subject code 17 may be represented by multipletranslations. A modification event requires deletion of a partition, andtherefore the deletion of all translation data (i.e., block structuresand target code) therein.

In a preferred embodiment, the translator 19 provides its own memorymanagement subsystem which mirrors the subject code partitions.Partitions are intended to group all translator data structures by thesubject code 17 regions to which they correspond. Portions of subjectcode 17 that are likely to be invalidated together form a partition: allrelated translator data structures therefore reside in the samewell-defined region of target memory. If a partition is invalidated, allof the translation data (translator structures and target code)associated with that partition can be freed en masse, avoiding the needto free every structure individually.

In this specific embodiment, the translator 19 performs all memoryallocation through memorySource objects. Each partition has onecorresponding memorySource. MemorySources obtain memory from theoperating system through conventional means such as mmap( ) systemcalls, but they do so in bulk. Other translator code (includingpseudo-target code) obtains memory as needed (i.e., in smallerquantities), but from per-partition memorySources rather than directlyfrom the operating system. This improves the performance of thetranslator 19 by reducing the number and frequency of underlyingmemory-related system calls. MemorySources also provide a function forflushing the entire contents of the memorySource at once. ThememorySource can implement a flush by actually freeing the underlyingmemory or by simply discarding all of the “allocations” it has made fromthat memory (i.e., wiping the slate clean while retaining the underlyingmemory).

The memory subsystem of the translator 19 also simplifies the process ofdeleting a partition. To delete a partition, the translator 19 must: (i)void the counterpart links of all predecessor partitions' exit guards;(ii) notify all successor partitions that their corresponding entryguards can be discarded; and (iii) delete all translation structures andtarget code belonging to the partition. Without the memory subsystem,the third step (iii) requires that the translator traverse theper-partition collections of translation structures and target code tofree each structure individually. With the memory subsystem, all of thepartition's structures can be freed at once by simply flushing thememorySource.

1. A method of grouping subject code during a translation of subjectcode into translated target code to account for self-modifying subjectcode, comprising: identifying self-modifying code events in said subjectcode during translation of subject code into translated code and alsoduring subsequent execution of translated code; and dividing a region ofmemory containing said subject code into at least one subjectinstruction group of subject addresses when identifying a self-modifyingcode event, wherein each subject instruction group includes one or moreranges of subject code addresses in said memory which are affected by arespective self-modifying code event.
 2. The method of claim 1, whereineach subject instruction group is further associated with translatedtarget code corresponding to subject code contained in that subjectinstruction group.
 3. The method of claim 1, wherein each said subjectinstruction group represents a region of memory that does not overlapwith regions of memory described by other subject instruction groups. 4.The method of claim 1, wherein each said subject instruction grouprepresents a region of memory that may overlap with regions of memorycontained in other subject instruction groups.
 5. The method of claim 1,wherein a self-modifying code event modifies a respective range ofsubject code addresses, said method further comprising: modifyingsubject instruction groups existing in said memory that contain subjectcode addresses which are affected by said self-modifying code event. 6.The method of claim 5, wherein said subject instruction group modifyingstep comprises: creating a new subject instruction group to includesubject code addresses containing modified subject code corresponding tothe self-modifying code event; and for existing subject instructiongroups having ranges of subject code addresses which overlap with thesubject code addresses of the newly created subject instruction group,modifying said existing subject instruction groups to delete the subjectcode addresses from said existing subject instruction groups thatoverlap with the subject code addresses of the newly created subjectinstruction groups such that the subject instruction groups no longeroverlap.
 7. The method of claim 6, wherein each subject instructiongroup is further associated with translated target code corresponding tosubject code contained in that subject instruction group, said methodfurther comprising: deleting translated target code associated withsubject instruction groups that have been modified in response to theself-modifying code event; and translating new target code for thesubject code contained in the modified subject instruction groups. 8.The method of claim 6, further comprising associating translated targetcode with a subject instruction group as its corresponding subject codecontained in that subject instruction group is translated.
 9. The methodof claim 8, wherein each subject instruction group includes a particularrange or ranges of subject code addresses that have been translated,such that the particular ranges of subject code addresses having beentranslated comprises an active sub-group within the subject instructiongroup, said method further comprising: determining whether the subjectcode addresses of said newly created subject instruction group overlapwith any subject code addresses in said active sub-group of any existingsubject instruction group; and for existing subject instruction groupshaving an active sub-group that overlaps with the subject code addressesof said newly created subject instruction group, deleting translatedtarget code associated with subject instruction groups that have beenmodified in response to the self-modifying code event, and translatingnew target code for the subject code contained in the modified subjectinstruction groups.
 10. The method of claim 9, wherein each subjectinstruction group includes a range or ranges of subject code addressesthat have not been translated referred to as an inactive sub-groupwithin the subject instruction group, said method further comprising:for existing subject instruction groups having an active sub-group whichdoes not overlap with the subject code addresses of said newly createdgroup but having an inactive sub-group that does overlap with thesubject code addresses of said newly created subject instruction group,modifying said existing subject instruction groups to delete the subjectcode addresses from said inactive sub-groups in said existing subjectinstruction groups that overlap with the subject code addresses of thenewly created subject instruction group such that the subjectinstruction groups no longer overlap, and leaving the translated targetcode associated with active sub-groups in said existing groupsunchanged.
 11. The method of claim 5, further comprising: identifyingsubject instruction groups that are adjacent to one another in memoryhaving characteristics that allow them to be combined; and aggregatingsaid adjacent subject instruction groups into a single, combined subjectinstruction group.
 12. The method of claim 1, wherein saidself-modifying code event is identified during decoding of the subjectcode, said method further comprising inserting a special translationstructure into a control flow of the translated target code as arepresentation of the identified self-modifying code event.
 13. Themethod of claim 12, in response to encountering said special translationstructure during execution of the translated target code, said methodfurther comprising: identifying the range or ranges of subject codeaddresses affected by the self-modifying code event, and creating thesubject instruction group in memory using this identified range ofsubject code addresses.
 14. The method of claim 1, further comprisingidentifying control flow instructions in the current subject instructiongroup which represent an actual or possible transfer of control tosubject addresses outside the current subject instruction group.
 15. Themethod of claim 14, wherein said control flow instruction is identifiedduring decoding of the subject code, said method further comprisinginserting a special exit translation structure into the control flow ofthe translated target code as a representation of the identified controlflow event.
 16. The method of claim 15, wherein control flow that passesfrom subject code in one subject instruction group into subject code ina different, second subject instruction group is represented using apair of special translation structures, wherein said pair of specialtranslation structures includes said exit structure and also an entrystructure, such that each exit structure contains a specific referenceto a counterpart entry structure associated with succeeding subjectinstruction group to be executed next.
 17. The method of claim 16, whenencountering an exit structure during execution of target codeassociated with a current subject instruction group, said method furthercomprising verifying that a counterpart entry structure exists in asuccessive subject instruction group before passing control from thecurrent partition to the successive group.
 18. The method of claim 17,when encountering an exit structure during execution of target codeassociated with a current subject instruction group, wherein said exitstructure is not associated with a counterpart entry structure existingin a successive subject instruction group, creating such an entrystructure and associating it with the appropriate successive subjectinstruction group which contains the successive subject address to beexecuted, and modifying said exit structure to specifically refer tosaid newly created entry structure.
 19. The method of claim 16, whereina set of border guards exists containing exit structures and entrystructures for all partitions, said method further comprising modifyingsaid set of exit structures and entry structures whenever a subjectinstruction group is deleted in response to a self-modifying code event.20. The method of claim 5, wherein when subject code defines amulti-threaded program, said method further comprising preventing otherthreads from entering a subject instruction group while the subjectinstruction group is being modified by another thread.
 21. The method ofclaim 5, wherein each subject instruction group is further associatedwith translated target code corresponding to subject addresses containedin that subject instruction group, wherein each partition includes a setof entry structures and exit structures represent control flow passingbetween subject instruction groups, such that each exit structurecontains a specific reference to a counterpart entry structure in asucceeding subject instruction group to be executed next, said methodfurther comprising: providing a memory management subsystem havingregions which mirror the subject instruction groups, wherein said memorymanagement subsystem stores target code and entry structures and exitstructures associated with a subject instruction group along with itscorresponding target code; and deleting an entire region of said memorymanagement subsystem that corresponds to a specific subject instructiongroup whenever that specific subject instruction group is modified. 22.A computer-readable storage medium having translator software residentthereon in the form of computer readable code executable by a computerfor performing a method of grouping subject code during a translation ofsubject code into translated target code to account for self-modifyingsubject code, said method comprising: identifying self-modifying codeevents in said subject code during translation of subject code intotranslated code and also during subsequent execution of translated code;and dividing a region of memory containing said subject code into atleast one subject instruction group of subject addresses whenidentifying a self-modifying code event, wherein each subjectinstruction group includes one or more ranges of subject code addressesin said memory which are affected by a respective self-modifying codeevent.
 23. The computer-readable storage medium of claim 22, whereineach subject instruction group is further associated with translatedtarget code corresponding to subject code contained in that subjectinstruction group.
 24. The computer-readable storage medium of claim 22,wherein each said subject instruction group represents a region ofmemory that does not overlap with regions of memory described by othersubject instruction groups.
 25. The computer-readable storage medium ofclaim 22, wherein each said subject instruction group represents aregion of memory that may overlap with regions of memory contained inother subject instruction groups.
 26. The computer-readable storagemedium of claim 22, wherein a self-modifying code event modifies arespective range of subject code addresses, said method furthercomprising: modifying subject instruction groups existing in said memorythat contain subject code addresses which are affected by saidself-modifying code event.
 27. The computer-readable storage medium ofclaim 26, wherein said subject instruction group modifying stepcomprises: creating a new subject instruction group to include subjectcode addresses containing modified subject code corresponding to theself-modifying code event; and for existing subject instruction groupshaving ranges of subject code addresses which overlap with the subjectcode addresses of the newly created subject instruction group, modifyingsaid existing subject instruction groups to delete the subject codeaddresses from said existing subject instruction groups that overlapwith the subject code addresses of the newly created subject instructiongroups such that the subject instruction groups no longer overlap. 28.The computer-readable storage medium of claim 27, wherein each subjectinstruction group is further associated with translated target codecorresponding to subject code contained in that subject instructiongroup, said method further comprising: deleting translated target codeassociated with subject instruction groups that have been modified inresponse to the self-modifying code event; and translating new targetcode for the subject code contained in the modified subject instructiongroups.
 29. The computer-readable storage medium of claim 27, saidmethod further comprising associating translated target code with asubject instruction group as its corresponding subject code contained inthat subject instruction group is translated.
 30. The computer-readablestorage medium of claim 29, wherein each subject instruction groupincludes a particular range or ranges of subject code addresses thathave been translated, such that the particular ranges of subject codeaddresses having been translated comprises an active sub-group withinthe subject instruction group, said method further comprising:determining whether the subject code addresses of said newly createdsubject instruction group overlap with any subject code addresses insaid active sub-group of any existing subject instruction group; and forexisting subject instruction groups having an active sub-group thatoverlaps with the subject code addresses of said newly created subjectinstruction group, deleting translated target code associated withsubject instruction groups that have been modified in response to theself-modifying code event, and translating new target code for thesubject code contained in the modified subject instruction groups. 31.The computer-readable storage medium of claim 30, wherein each subjectinstruction group includes a range or ranges of subject code addressesthat have not been translated referred to as an inactive sub-groupwithin the subject instruction group, said method further comprising:for existing subject instruction groups having an active sub-group whichdoes not overlap with the subject code addresses of said newly createdgroup but having an inactive sub-group that does overlap with thesubject code addresses of said newly created subject instruction group,modifying said existing subject instruction groups to delete the subjectcode addresses from said inactive sub-groups in said existing subjectinstruction groups that overlap with the subject code addresses of thenewly created subject instruction group such that the subjectinstruction groups no longer overlap, and leaving the translated targetcode associated with active sub-groups in said existing groupsunchanged.
 32. The computer-readable storage medium of claim 26, saidmethod further comprising: identifying subject instruction groups thatare adjacent to one another in memory having characteristics that allowthem to be combined; and aggregating said adjacent subject instructiongroups into a single, combined subject instruction group.
 33. Thecomputer-readable storage medium of claim 22, wherein saidself-modifying code event is identified during decoding of the subjectcode, said method further comprising inserting a special translationstructure into a control flow of the translated target code as arepresentation of the identified self-modifying code event.
 34. Thecomputer-readable storage medium of claim 33, in response toencountering said special translation structure during execution of thetranslated target code, said method further comprising: identifying therange or ranges of subject code addresses affected by the self-modifyingcode event, and creating the subject instruction group in memory usingthis identified range of subject code addresses.
 35. Thecomputer-readable storage medium of claim 22, said method furthercomprising identifying control flow instructions in the current subjectinstruction group which represent an actual or possible transfer ofcontrol to subject addresses outside the current subject instructiongroup.
 36. The computer-readable storage medium of claim 35, whereinsaid control flow instruction is identified during decoding of thesubject code, said method further comprising inserting a special exittranslation structure into the control flow of the translated targetcode as a representation of the identified control flow event.
 37. Thecomputer-readable storage medium of claim 36, wherein control flow thatpasses from subject code in one subject instruction group into subjectcode in a different, second subject instruction group is representedusing a pair of special translation structures, wherein said pair ofspecial translation structures includes said exit structure and also anentry structure, such that each exit structure contains a specificreference to a counterpart entry structure associated with succeedingsubject instruction group to be executed next.
 38. The computer-readablestorage medium of claim 37, when encountering an exit structure duringexecution of target code associated with a current subject instructiongroup, said method further comprising verifying that a counterpart entrystructure exists in a successive subject instruction group beforepassing control from the current partition to the successive group. 39.The computer-readable storage medium of claim 38, when encountering anexit structure during execution of target code associated with a currentsubject instruction group, wherein said exit structure is not associatedwith a counterpart entry structure existing in a successive subjectinstruction group, said method further comprising creating such an entrystructure and associating it with the appropriate successive subjectinstruction group which contains the successive subject address to beexecuted, and modifying said exit structure to specifically refer tosaid newly created entry structure.
 40. The computer-readable storagemedium of claim 37, wherein a set of border guards exists containingexit structures and entry structures for all partitions, said methodfurther comprising modifying said set of exit structures and entrystructures whenever a subject instruction group is deleted in responseto a self-modifying code event.
 41. The computer-readable storage mediumof claim 26, wherein when subject code defines a multi-threaded program,said method further comprising preventing other threads from entering asubject instruction group while the subject instruction group is beingmodified by another thread.
 42. The computer-readable storage medium ofclaim 26, wherein each subject instruction group is further associatedwith translated target code corresponding to subject addresses containedin that subject instruction group, wherein each partition includes a setof entry structures and exit structures represent control flow passingbetween subject instruction groups, such that each exit structurecontains a specific reference to a counterpart entry structure in asucceeding subject instruction group to be executed next, said methodfurther comprising: providing a memory management subsystem havingregions which mirror the subject instruction groups, wherein said memorymanagement subsystem stores target code and entry structures and exitstructures associated with a subject instruction group along with itscorresponding target code; and deleting an entire region of said memorymanagement subsystem that corresponds to a specific subject instructiongroup whenever that specific subject instruction group is modified. 43.In combination: a target processor; and translator code for performing amethod of grouping subject code during a translation of subject codeinto translated target code to account for self-modifying subject code,said translator code comprising code executable by said target processorfor performing the following steps: identifying self-modifying codeevents in said subject code during translation of subject code intotranslated code and also during subsequent execution of translated code;and dividing a region of memory containing said subject code into atleast one subject instruction group of subject addresses whenidentifying a self-modifying code event, wherein each subjectinstruction group includes one or more ranges of subject code addressesin said memory which are affected by a respective self-modifying codeevent.
 44. The combination of claim 43, wherein each subject instructiongroup is further associated with translated target code corresponding tosubject code contained in that subject instruction group.
 45. Thecombination of claim 43, wherein each said subject instruction grouprepresents a region of memory that does not overlap with regions ofmemory described by other subject instruction groups.
 46. Thecombination of claim 43, wherein each said subject instruction grouprepresents a region of memory that may overlap with regions of memorycontained in other subject instruction groups.
 47. The combination ofclaim 43, wherein a self-modifying code event modifies a respectiverange of subject code addresses, said translator code further comprisingcode executable by said target processor for: modifying subjectinstruction groups existing in said memory that contain subject codeaddresses which are affected by said self-modifying code event.
 48. Thecombination of claim 47, wherein said subject instruction groupmodifying step comprises: creating a new subject instruction group toinclude subject code addresses containing modified subject codecorresponding to the self-modifying code event; and for existing subjectinstruction groups having ranges of subject code addresses which overlapwith the subject code addresses of the newly created subject instructiongroup, modifying said existing subject instruction groups to delete thesubject code addresses from said existing subject instruction groupsthat overlap with the subject code addresses of the newly createdsubject instruction groups such that the subject instruction groups nolonger overlap.
 49. The combination of claim 48, wherein each subjectinstruction group is further associated with translated target codecorresponding to subject code contained in that subject instructiongroup, said translator code further comprising code executable by saidtarget processor for: deleting translated target code associated withsubject instruction groups that have been modified in response to theself-modifying code event; and translating new target code for thesubject code contained in the modified subject instruction groups. 50.The combination of claim 48, further comprising associating translatedtarget code with a subject instruction group as its correspondingsubject code contained in that subject instruction group is translated.51. The combination of claim 50, wherein each subject instruction groupincludes a particular range or ranges of subject code addresses thathave been translated, such that the particular ranges of subject codeaddresses having been translated comprises an active sub-group withinthe subject instruction group, said translator code further comprisingcode executable by said target processor for: determining whether thesubject code addresses of said newly created subject instruction groupoverlap with any subject code addresses in said active sub-group of anyexisting subject instruction group; and for existing subject instructiongroups having an active sub-group that overlaps with the subject codeaddresses of said newly created subject instruction group, deletingtranslated target code associated with subject instruction groups thathave been modified in response to the self-modifying code event, andtranslating new target code for the subject code contained in themodified subject instruction groups.
 52. The combination of claim 51,wherein each subject instruction group includes a range or ranges ofsubject code addresses that have not been translated referred to as aninactive sub-group within the subject instruction group, said translatorcode further comprising code executable by said target processor for:for existing subject instruction groups having an active sub-group whichdoes not overlap with the subject code addresses of said newly createdgroup but having an inactive sub-group that does overlap with thesubject code addresses of said newly created subject instruction group,modifying said existing subject instruction groups to delete the subjectcode addresses from said inactive sub-groups in said existing subjectinstruction groups that overlap with the subject code addresses of thenewly created subject instruction group such that the subjectinstruction groups no longer overlap, and leaving the translated targetcode associated with active sub-groups in said existing groupsunchanged.
 53. The combination of claim 47, said translator code furthercomprising code executable by said target processor for: identifyingsubject instruction groups that are adjacent to one another in memoryhaving characteristics that allow them to be combined; and aggregatingsaid adjacent subject instruction groups into a single, combined subjectinstruction group.
 54. The combination of claim 43, wherein saidself-modifying code event is identified during decoding of the subjectcode, said translator code further comprising code executable by saidtarget processor for inserting a special translation structure into acontrol flow of the translated target code as a representation of theidentified self-modifying code event.
 55. The combination of claim 54,in response to encountering said special translation structure duringexecution of the translated target code, said translator code furthercomprising code executable by said target processor for: identifying therange or ranges of subject code addresses affected by the self-modifyingcode event, and creating the subject instruction group in memory usingthis identified range of subject code addresses.
 56. The combination ofclaim 43, said translator code further comprising code executable bysaid target processor for identifying control flow instructions in thecurrent subject instruction group which represent an actual or possibletransfer of control to subject addresses outside the current subjectinstruction group.
 57. The combination of claim 56, wherein said controlflow instruction is identified during decoding of the subject code, saidtranslator code further comprising code executable by said targetprocessor for inserting a special exit translation structure into thecontrol flow of the translated target code as a representation of theidentified control flow event.
 58. The combination of claim 57, whereincontrol flow that passes from subject code in one subject instructiongroup into subject code in a different, second subject instruction groupis represented using a pair of special translation structures, whereinsaid pair of special translation structures includes said exit structureand also an entry structure, such that each exit structure contains aspecific reference to a counterpart entry structure associated withsucceeding subject instruction group to be executed next.
 59. Thecombination of claim 58, when encountering an exit structure duringexecution of target code associated with a current subject instructiongroup, said translator code further comprising code executable by saidtarget processor for verifying that a counterpart entry structure existsin a successive subject instruction group before passing control fromthe current partition to the successive group.
 60. The combination ofclaim 59, when encountering an exit structure during execution of targetcode associated with a current subject instruction group, wherein saidexit structure is not associated with a counterpart entry structureexisting in a successive subject instruction group, said translator codefurther comprising code executable by said target processor for creatingsuch an entry structure and associating it with the appropriatesuccessive subject instruction group which contains the successivesubject address to be executed, and modifying said exit structure tospecifically refer to said newly created entry structure.
 61. Thecombination of claim 58, wherein a set of border guards existscontaining exit structures and entry structures for all partitions, saidtranslator code further comprising code executable by said targetprocessor for modifying said set of exit structures and entry structureswhenever a subject instruction group is deleted in response to aself-modifying code event.
 62. The combination of claim 47, wherein whensubject code defines a multi-threaded program, said translator codefurther comprising code executable by said target processor forpreventing other threads from entering a subject instruction group whilethe subject instruction group is being modified by another thread. 63.The combination of claim 47, wherein each subject instruction group isfurther associated with translated target code corresponding to subjectaddresses contained in that subject instruction group, wherein eachpartition includes a set of entry structures and exit structuresrepresent control flow passing between subject instruction groups, suchthat each exit structure contains a specific reference to a counterpartentry structure in a succeeding subject instruction group to be executednext, said translator code further comprising code executable by saidtarget processor for: providing a memory management subsystem havingregions which mirror the subject instruction groups, wherein said memorymanagement subsystem stores target code and entry structures and exitstructures associated with a subject instruction group along with itscorresponding target code; and deleting an entire region of said memorymanagement subsystem that corresponds to a specific subject instructiongroup whenever that specific subject instruction group is modified.